Expectation Rubrics

Example of an expectation rubric#

For example, let's assume you work for a company that uses a three-level performance review system: for any given expectation, employees are "Exceeding expectations," "Meeting expectations," or receiving a "Needs improvement." (Note that I'm not advocating such a scale, just using this as an example. Some companies will prefer a four- or five-tiered system, some will look to use a 10-point scale, and so on.)

Then, for an expectation of "Writes good code," we might create a rubric that looks like the following (for the code written by this individual):

• Exceeds expectations. Code is well-organized: each method does one and only one thing, methods are named correctly, and length is less than 20 lines in length. Engineers who have never seen the code before can look at the code and understand it well enough to offer up a description of its implementation in less than an hour's worth of review. Comments provide implementation insight, rather than just restate the obvious.

• Meets expectations. Code solves the problem it sets out to solve, but it could be optimized: it uses a brute-force algorithm instead of something more efficient, it creates a number of temporary objects that could be removed, and so on. Other team members reviewing the code have questions about its implementation after less than an hour's worth of review.

• Needs improvement. Code contains numerous violations of DRY (don't repeat yourself) or SOLID principles. Implementation does not conform to our coding conventions and/or requires significant fixes. Code contains comments that are either redundant or recursive (A says to see B, B says to see A), or comments are missing. Other engineers require much more than an hour to understand anything about the code.

Again, this is only an example of a rubric, and one that stresses the organization and "communicative" capabilities of the code. For another team that ships libraries for high-performance calculation scenarios, the rubric would probably need to contain performance-related evaluation elements.

When creating a rubric, one way to ascertain its utility is to ask a peer manager to use the rubric in an informal way to evaluate somebody on your team or their team. Think of it as a unit-test. Take an employee who fits your intuitive understanding of a particular level ("Matt is an exceeds-expectations engineer"), and ask your peer to use the rubric to examine that individual's performance. "Hey, Kim, would you mind taking some of Matt's code and running it through my rubric and give me your results?" If your peer can use the rubric and come to the same result you would, there's a good chance the rubric is serving its intended purpose.